Verkkoturvallisuuden otsakkeet: Content Security Policy ja JavaScriptin suorittaminen

Nykypäivän monimutkaisessa digitaalisessa ympäristössä verkkosovellusten tietoturva on ensiarvoisen tärkeää. Yksi tehokkaimmista puolustuskeinoista erilaisia hyökkäyksiä, erityisesti sivustojen välistä komentosarjasuoritusta (Cross-Site Scripting, XSS), vastaan on verkkoturvallisuuden otsakkeiden käyttö. Näistä Content Security Policy (CSP) erottuu tehokkaana mekanismina, jolla hallitaan resursseja, joita selain saa ladata tietylle sivulle. Tämä artikkeli tarjoaa kattavan oppaan CSP:n ymmärtämiseen ja tehokkaaseen käyttöönottoon verkkosovellusten ja käyttäjien suojaamiseksi.

Verkkoturvallisuuden otsakkeiden ymmärtäminen

Verkkoturvallisuuden otsakkeet ovat HTTP-vastausotsakkeita, jotka antavat selaimelle ohjeita siitä, miten tietyntyyppistä sisältöä käsitellään. Ne ovat ratkaiseva osa syvyyspuolustusstrategiaa ja toimivat yhdessä muiden turvatoimien kanssa riskien vähentämiseksi.

Joitakin yleisimmin käytettyjä verkkoturvallisuuden otsakkeita ovat:

• Content Security Policy (CSP): Hallitsee resursseja, joita käyttäjäagentti saa ladata.
• HTTP Strict Transport Security (HSTS): Pakottaa selaimet käyttämään HTTPS-protokollaa.
• X-Frame-Options: Suojaa Clickjacking-hyökkäyksiltä.
• X-Content-Type-Options: Estää MIME-haisteluun liittyviä haavoittuvuuksia.
• Referrer-Policy: Hallitsee, kuinka paljon viittaajatietoja pyyntöihin sisällytetään.
• Permissions-Policy (aiemmin Feature-Policy): Mahdollistaa selaimen ominaisuuksien tarkan hallinnan.

Tämä artikkeli keskittyy pääasiassa Content Security Policyyn (CSP) ja sen vaikutukseen JavaScriptin suorittamiseen.

Mikä on Content Security Policy (CSP)?

CSP on HTTP-vastausotsake, jonka avulla voit määrittää sallittujen lähteiden luettelon, joista selain saa ladata resursseja. Tämä sisältää JavaScriptin, CSS:n, kuvat, fontit ja muut resurssit. Määrittämällä nämä luotetut lähteet nimenomaisesti voit vähentää merkittävästi XSS-hyökkäysten riskiä, joissa haitallisia skriptejä syötetään verkkosivustollesi ja suoritetaan käyttäjien selaimien kontekstissa.

Voit ajatella CSP:tä selaimen palomuurina, mutta verkkoliikenteen estämisen sijaan se estää epäluotettavan koodin suorittamisen.

Miksi CSP on tärkeä JavaScriptin suorittamiselle?

JavaScript on tehokas kieli, jota voidaan käyttää dynaamisten ja interaktiivisten verkkokokemusten luomiseen. Sen joustavuus tekee siitä kuitenkin myös ensisijaisen kohteen hyökkääjille. XSS-hyökkäykset sisältävät usein haitallisen JavaScript-koodin syöttämisen verkkosivustolle, jota voidaan sitten käyttää käyttäjien tunnusten varastamiseen, käyttäjien ohjaamiseen tietojenkalastelusivustoille tai verkkosivuston turmelemiseen.

CSP voi tehokkaasti estää nämä hyökkäykset rajoittamalla lähteitä, joista JavaScriptiä voidaan ladata ja suorittaa. Oletusarvoisesti CSP estää kaiken inline-JavaScriptin (koodin <script>-tagien sisällä) ja ulkoisista verkkotunnuksista ladatun JavaScriptin. Tämän jälkeen voit valikoivasti sallia luotettuja lähteitä CSP-direktiivien avulla.

CSP-direktiivit: Politiikkasi rakennuspalikat

CSP-direktiivit määrittelevät, minkä tyyppisiä resursseja saa ladata ja mistä lähteistä niitä voidaan ladata. Tässä on joitakin tärkeimpiä direktiivejä:

• default-src: Toimii oletusarvona muille noutodirektiiveille. Jos tiettyä direktiiviä ei ole määritelty, käytetään default-src-direktiiviä.
• script-src: Määrittelee sallitut lähteet JavaScript-koodille.
• style-src: Määrittelee sallitut lähteet CSS-tyylisivuille.
• img-src: Määrittelee sallitut lähteet kuville.
• font-src: Määrittelee sallitut lähteet fonteille.
• media-src: Määrittelee sallitut lähteet ääni- ja videotiedostoille.
• object-src: Määrittelee sallitut lähteet liitännäisille (esim. Flash).
• frame-src: Määrittelee sallitut lähteet kehyksille (<frame>, <iframe>).
• connect-src: Määrittelee sallitut alkuperät verkkopyynnöille (esim. XMLHttpRequest, Fetch API, WebSockets).
• base-uri: Rajoittaa URL-osoitteita, joita voidaan käyttää dokumentin <base>-elementissä.
• form-action: Rajoittaa URL-osoitteita, joihin lomakkeita voidaan lähettää.
• upgrade-insecure-requests: Ohjeistaa selainta päivittämään kaikki suojaamattomat URL-osoitteet (HTTP) suojatuiksi URL-osoitteiksi (HTTPS).
• block-all-mixed-content: Estää selainta lataamasta mitään resursseja HTTP:n kautta, kun sivu ladataan HTTPS:n kautta.

Jokainen direktiivi voi hyväksyä erilaisia lähdemäärityksiä, mukaan lukien:

• *: Sallii resurssit mistä tahansa lähteestä (yleensä ei suositella).
• 'self': Sallii resurssit samasta alkuperästä (protokolla, isäntä ja portti) kuin dokumentti.
• 'none': Estää resurssit kaikista lähteistä.
• 'unsafe-inline': Sallii inline-JavaScriptin ja -CSS:n käytön (vahvasti ei-suositeltavaa).
• 'unsafe-eval': Sallii eval()-funktion ja vastaavien funktioiden käytön (vahvasti ei-suositeltavaa).
• 'unsafe-hashes': Sallii tietyt inline-tapahtumankäsittelijät niiden SHA256-, SHA384- tai SHA512-tiivisteen perusteella (käytä varoen).
• data:: Sallii data: URI -osoitteet (esim. base64-koodatut inline-kuvat).
• https://example.com: Sallii resurssit määritetystä verkkotunnuksesta (ja valinnaisesti portista) HTTPS:n kautta.
• *.example.com: Sallii resurssit mistä tahansa example.com-verkkotunnuksen aliverkkotunnuksesta.
• nonce-{random-value}: Sallii tietyt inline-skriptit tai -tyylit, joilla on vastaava nonce-attribuutti (suositellaan inline-koodille).
• sha256-{hash-value}: Sallii tietyt inline-skriptit tai -tyylit, joilla on vastaava SHA256-tiiviste (vaihtoehto nonce-arvoille).

CSP:n käyttöönotto: Käytännön esimerkkejä

CSP voidaan ottaa käyttöön kahdella päätavalla:

1. HTTP-otsake: Lähettämällä Content-Security-Policy-otsake HTTP-vastauksessa. Tämä on suositeltava menetelmä.
2. <meta>-tagi: Käyttämällä <meta>-tagia HTML-dokumentin <head>-osiossa. Tällä menetelmällä on rajoituksia, eikä sitä yleensä suositella.

HTTP-otsakkeen käyttäminen

Asettaaksesi CSP-otsakkeen sinun on määritettävä verkkopalvelimesi. Tarkat vaiheet vaihtelevat palvelimesi mukaan (esim. Apache, Nginx, IIS).

Tässä on joitakin esimerkkejä CSP-otsakkeista:

Perus-CSP

Tämä politiikka sallii resurssit vain samasta alkuperästä:

            Content-Security-Policy: default-src 'self';
            

              
                Copy
              
            
          

Resurssien salliminen tietyistä verkkotunnuksista

Tämä politiikka sallii JavaScriptin osoitteesta https://cdn.example.com ja kuvat osoitteesta https://images.example.net:

            Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; img-src 'self' https://images.example.net;
            

              
                Copy
              
            
          

Nonce-arvojen käyttäminen inline-skripteille

Tämä politiikka sallii inline-skriptit, joilla on vastaava nonce-attribuutti:

            Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-rAnd0mN0nc3';
            

              
                Copy
              
            
          

HTML-koodissasi:

            <script nonce="rAnd0mN0nc3">
 // Sinun inline-skriptisi
</script>
            

              
                Copy
              
            
          

Huomautus: Nonce-arvo tulisi luoda satunnaisesti jokaista pyyntöä varten, jotta hyökkääjät eivät voi ohittaa CSP:tä.

Tiivisteiden (hash) käyttäminen inline-skripteille

Tämä politiikka sallii tietyt inline-skriptit niiden SHA256-tiivisteen perusteella:

            Content-Security-Policy: default-src 'self'; script-src 'self' 'sha256-qznLcsROx4GACP2dm0UCKCzCG+HiZ1guq6ZZDob/Tng=';
            

              
                Copy
              
            
          

Voit luoda SHA256-tiivisteen käyttämällä erilaisia verkkotyökaluja tai komentorivityökaluja (esim. openssl dgst -sha256 -binary input.js | openssl base64).

<meta>-tagin käyttäminen

Vaikka sitä ei suositella monimutkaisille politiikoille, <meta>-tagia voidaan käyttää perus-CSP:n asettamiseen. Esimerkiksi:

            <meta http-equiv="Content-Security-Policy" content="default-src 'self';">
            

              
                Copy
              
            
          

<meta>-tagin rajoitukset:

• Ei voi käyttää report-uri-direktiivin määrittämiseen.
• Ei ole yhtä laajasti tuettu kuin HTTP-otsake.
• Vähemmän joustava ja vaikeampi hallita monimutkaisissa politiikoissa.

CSP:n vain raportointi -tila

Ennen CSP:n täytäntöönpanoa on erittäin suositeltavaa käyttää Content-Security-Policy-Report-Only-otsaketta. Tämä antaa sinun seurata politiikkasi vaikutusta estämättä mitään resursseja. Selain raportoi kaikki rikkomukset määritettyyn URL-osoitteeseen, jolloin voit hienosäätää politiikkaasi ennen sen käyttöönottoa tuotannossa.

            Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-report;
            

              
                Copy
              
            
          

Sinun on määritettävä palvelinpuolen päätepiste (esim. /csp-report) vastaanottamaan ja käsittelemään CSP-raportteja. Nämä raportit ovat tyypillisesti JSON-objekteja, jotka sisältävät tietoja rikotusta direktiivistä, estetty URI:sta ja muista asiaankuuluvista yksityiskohdista.

Yleiset CSP-virheet ja niiden välttäminen

CSP:n käyttöönotto voi olla haastavaa, ja on helppo tehdä virheitä, jotka voivat joko heikentää tietoturvaasi tai rikkoa verkkosivustosi. Tässä on joitakin yleisiä sudenkuoppia, joita tulee välttää:

• 'unsafe-inline'- ja 'unsafe-eval'-direktiivien käyttö: Nämä direktiivit käytännössä poistavat CSP:n tarjoaman suojan, ja niitä tulisi välttää aina kun mahdollista. Käytä nonce-arvoja tai tiivisteitä inline-skripteille ja vältä eval()-funktion käyttöä.
• *-merkin käyttö: Resurssien salliminen mistä tahansa lähteestä kumoaa CSP:n tarkoituksen. Ole mahdollisimman tarkka määrittäessäsi politiikkaasi.
• Riittämätön testaus: Testaa aina CSP:tä vain raportointi -tilassa ennen sen täytäntöönpanoa. Seuraa raportteja ja säädä politiikkaasi tarpeen mukaan.
• Virheellinen report-uri-määritys: Varmista, että report-uri-päätepiste on määritetty oikein vastaanottamaan ja käsittelemään CSP-raportteja.
• CSP:n päivittämättä jättäminen: Kun verkkosivustosi kehittyy, CSP:täsi saatetaan joutua päivittämään vastaamaan resurssiriippuvuuksien muutoksia.
• Liian rajoittavat politiikat: Liian rajoittavat politiikat voivat rikkoa verkkosivustosi ja turhauttaa käyttäjiä. Löydä tasapaino turvallisuuden ja käytettävyyden välillä.

CSP ja kolmannen osapuolen kirjastot

Monet verkkosivustot tukeutuvat kolmannen osapuolen kirjastoihin ja palveluihin, kuten CDN-verkkoihin, analytiikkatoimittajiin ja sosiaalisen median widgetteihin. CSP:tä käyttöönotettaessa on tärkeää ottaa nämä riippuvuudet huomioon ja varmistaa, että politiikkasi sallii niiden ladata resursseja oikein.

Tässä on joitakin strategioita kolmannen osapuolen kirjastojen käsittelyyn:

• Salli nimenomaisesti luotettujen kolmannen osapuolen toimittajien verkkotunnukset: Esimerkiksi, jos käytät jQueryä CDN-verkosta, lisää CDN:n verkkotunnus script-src-direktiiviisi.
• Käytä Subresource Integrity (SRI) -ominaisuutta: SRI:n avulla voit varmistaa, että kolmannen osapuolen lähteistä lataamiasi tiedostoja ei ole peukaloitu. SRI:n käyttämiseksi sinun on luotava tiedostosta kryptografinen tiiviste ja sisällytettävä se <script>- tai <link>-tagiin.
• Harkitse kolmannen osapuolen kirjastojen isännöintiä omalla palvelimellasi: Tämä antaa sinulle enemmän hallintaa resursseista ja vähentää riippuvuuttasi ulkoisista toimittajista.

Esimerkki SRI:n käytöstä:

            <script
 src="https://cdn.example.com/jquery.min.js"
 integrity="sha384-vtXRMe3mGCkKsTB9UMvnoknreNzcMRujMQFFSQhtI2zxLlClmHsfq9em6JzhbqQ"
 crossorigin="anonymous"></script>
            

              
                Copy
              
            
          

CSP ja yhden sivun sovellukset (SPA)

Yhden sivun sovellukset (SPA) tukeutuvat usein voimakkaasti JavaScriptiin ja dynaamiseen koodin generointiin, mikä voi tehdä CSP:n käyttöönotosta haastavampaa. Tässä on joitakin vinkkejä SPA-sovellusten suojaamiseen CSP:llä:

• Vältä 'unsafe-eval'-direktiivin käyttöä: SPA-sovellukset käyttävät usein mallinnusmoottoreita tai muita tekniikoita, jotka perustuvat eval()-funktioon. Harkitse sen sijaan vaihtoehtoisia lähestymistapoja, jotka eivät vaadi eval()-funktiota, kuten esikäännettyjä malleja.
• Käytä nonce-arvoja tai tiivisteitä inline-skripteille: SPA-sovellukset syöttävät usein JavaScript-koodia dynaamisesti. Käytä nonce-arvoja tai tiivisteitä varmistaaksesi, että vain luotettua koodia suoritetaan.
• Määritä connect-src-direktiivi huolellisesti: SPA-sovellukset tekevät usein API-pyyntöjä eri päätepisteisiin. Varmista, että sallit vain tarvittavat verkkotunnukset connect-src-direktiivissä.
• Harkitse CSP-tietoisen viitekehyksen käyttöä: Jotkin JavaScript-viitekehykset tarjoavat sisäänrakennetun tuen CSP:lle, mikä helpottaa turvallisen politiikan käyttöönottoa ja ylläpitoa.

CSP ja kansainvälistäminen (i18n)

Kun kehitetään verkkosovelluksia maailmanlaajuiselle yleisölle, on tärkeää ottaa huomioon CSP:n vaikutus kansainvälistämiseen (i18n). Tässä on joitakin tekijöitä, jotka kannattaa pitää mielessä:

• Sisällönjakeluverkot (CDN): Jos käytät CDN-verkkoa verkkosivustosi resurssien jakeluun, varmista, että sallit CDN:n verkkotunnukset CSP:ssäsi. Harkitse eri CDN-verkkojen käyttöä eri alueille suorituskyvyn optimoimiseksi.
• Ulkoiset fontit: Jos käytät ulkoisia fontteja (esim. Google Fonts), varmista, että sallit fonttitoimittajien verkkotunnukset font-src-direktiivissäsi.
• Lokalisoitu sisältö: Jos tarjoat eri versioita verkkosivustostasi eri kielille tai alueille, varmista, että CSP on määritetty oikein jokaiselle versiolle.
• Kolmannen osapuolen integraatiot: Jos integroitut kolmannen osapuolen palveluihin, jotka ovat ominaisia tietyille alueille, varmista, että sallit näiden palveluiden verkkotunnukset CSP:ssäsi.

CSP:n parhaat käytännöt: Globaali näkökulma

Tässä on joitakin yleisiä parhaita käytäntöjä CSP:n käyttöönottoon, ottaen huomioon globaalin näkökulman:

• Aloita rajoittavalla politiikalla: Aloita politiikalla, joka estää kaiken oletusarvoisesti, ja salli sitten valikoivasti luotettuja lähteitä.
• Käytä ensin vain raportointi -tilaa: Testaa CSP:tä vain raportointi -tilassa ennen sen täytäntöönpanoa mahdollisten ongelmien tunnistamiseksi.
• Seuraa CSP-raportteja: Tarkista säännöllisesti CSP-raportteja mahdollisten tietoturvahaavoittuvuuksien tunnistamiseksi ja politiikkasi hiomiseksi.
• Käytä nonce-arvoja tai tiivisteitä inline-skripteille: Vältä 'unsafe-inline'- ja 'unsafe-eval'-direktiivien käyttöä.
• Ole tarkka lähdeluetteloissasi: Vältä yleismerkkien (*) käyttöä, ellei se ole ehdottoman välttämätöntä.
• Käytä Subresource Integrity (SRI) -ominaisuutta kolmannen osapuolen resursseille: Varmista CDN-verkoista ladattujen tiedostojen eheys.
• Pidä CSP ajan tasalla: Tarkista ja päivitä CSP:täsi säännöllisesti vastaamaan verkkosivustosi ja riippuvuuksien muutoksia.
• Kouluta tiimiäsi: Varmista, että kehittäjäsi ja tietoturvatiimisi ymmärtävät CSP:n tärkeyden ja sen oikean käyttöönoton.
• Harkitse CSP-generaattorin tai -hallintatyökalun käyttöä: Nämä työkalut voivat auttaa sinua luomaan ja ylläpitämään CSP:täsi helpommin.
• Dokumentoi CSP:si: Dokumentoi CSP-politiikkasi ja kunkin direktiivin perustelut auttaaksesi tulevia kehittäjiä ymmärtämään ja ylläpitämään sitä.

Yhteenveto

Content Security Policy on tehokas työkalu XSS-hyökkäysten torjuntaan ja verkkosovellusten turvallisuuden parantamiseen. Määrittämällä huolellisesti sallittujen lähteiden luettelon voit vähentää merkittävästi haitallisen koodin suorittamisen riskiä ja suojata käyttäjiäsi vahingoilta. CSP:n käyttöönotto voi olla haastavaa, mutta noudattamalla tässä artikkelissa esitettyjä parhaita käytäntöjä ja ottamalla huomioon sovelluksesi ja maailmanlaajuisen yleisösi erityistarpeet, voit luoda vankan ja tehokkaan tietoturvapolitiikan, joka suojaa verkkosivustoasi ja käyttäjiäsi maailmanlaajuisesti.

Muista, että tietoturva on jatkuva prosessi, ja CSP on vain yksi osa palapeliä. Yhdistä CSP muihin turvatoimiin, kuten syötteen validointiin, tulosteen koodaukseen ja säännöllisiin tietoturvatarkastuksiin, luodaksesi kattavan syvyyspuolustusstrategian.

Lisämateriaalia

• Content Security Policy (CSP) - MDN Web Docs
• CSP-arvioija
• Content-Security-Policy.com